No perfect options, but a few workarounds possible

a connector-like proxy which would intercept Client Credentials requests from their customers and use business logic to validate the client secret against the stored Duende hash. stand up a simple proxy in front of the Duende that logs the plaintext client secrets for a period of time before migration (protect these logs of course) go to each client and ask them to use a new FusionAuth specific client secret (analogous to resetting user passwords)

More details on the first option. It requires these steps/prereqs:

FusionAuth Entities Setup The customer should create new FusionAuth Entities that correlate to the Client ID of all APIs and services currently associated with Duende. For now, let FusionAuth generate a random Client Secret. Custom Attribute for Migration: Store a custom attribute such as migration: false on entity.data for all newly created Entities. Migration Steps API/Service Requests Token: The API or service calls Duende's token endpoint. Proxy Interception: The customer's proxy intercepts the client credentials request and searches FusionAuth Entities to find the matching Entity by Client ID. Migration Check: Use an if/else logic to check if migration: false exists for this client ID. If so, the proxy service proceeds with the client credentials request to Duende using the Client ID and Secret (in plain text). JWT Validation: If Duende responds with a JWT, this confirms the Client Secret is correct. The proxy service discards Duende's JWT and then calls the Entity API to update the correct Client Secret and set migration: true on the entity.data object. Complete Migration: The proxy service calls FusionAuth's token endpoint to complete the Client Credentials grant. The proxy service then returns a JWT to the end customer’s API/service, migration is complete.

Which of these make sense depend on how many clients you have, your dev teams bandwidth, and your security posture.

@shyamsundar-k said in How to generate and authorized java spring controller using JWT:

We need to pass the token in the API header as Authorization: Bearer<token> But what is the process so that I can validate the endpoint with the valid token if the token is invalid or does not have the required roles or scope then I should get 401 else I should be able to access the API successfully.

Once you have a token in your API, you can validate it in two different ways. But it's worth noting that to validate the token, you must validate the signature and then the claims.

First option: use a library to validate the signature. Most languages have options. For java, you can use fusionauth-jwt, the readme has sample code.

Second option: use the validate API. You could use the FusionAuth client library to make this call if you'd like.

The first means you have to pick a library. The second means you have to make a network call.

Either way, after you validate the signature, you need to check the claims (issuer, audience, expiration, custom claims) to make sure they are what you expect.

Here's more about how to consume a JWT.

The tenant is using the "Default signing key (HS256)" for the access token.

@arjunyel

Connectors are documented here: https://fusionauth.io/docs/v1/tech/connectors/

Machine to machine auth is the client credentials grant: https://fusionauth.io/docs/v1/tech/oauth/#example-client-credentials-grant

Does 100 Machine To Machine Auth mean you can have 100 API entities?

Yes, that is correct.

An update! The client credentials grant is now available in paid editions of FusionAuth.

Here is the documentation:

https://fusionauth.io/docs/v1/tech/oauth/#configure-entities

https://fusionauth.io/docs/v1/tech/oauth/#example-client-credentials-grant